Programmable controllers, including Programmable Logic Controllers (“PLCs”) are used in many commercial and industrial applications. Programmable controllers typically monitor inputs, make decisions based on how they are programmed, and control outputs of automated processes or machines. One of the most common programmable controllers in use is the PLC. PLCs consist of input modules or points, a Central Processing Unit (“CPU”), and output modules or points. An input accepts a variety of digital or analog signals from various field devices, such as sensors, and converts them into a logic signal that can be used by the CPU. The CPU makes decisions and executes control instructions based on programming instructions stored in a memory. These programming instructions determine what the PLC will do for a specific input. Output modules convert the control instructions from the CPU into a digital or analog signal that can be used to control various field devices, such as actuators or valves.
Since most programmable controllers, including PLC's, are in essence computers, they store information in the form of On or Off conditions (i.e. 1s or 0s), referred to as binary digits (i.e. bits). A program for a programmable controller consists of one or more instructions that accomplish a task. Programming a PLC or other controller is a matter of constructing a set of instructions. Programming usually also involves generating configuration data. Configuring a programmable controller involves mapping the controller's input/output )(“I/O”) area to the physical I/O. Configuration editors are generally graphical.
There are several ways to look at a program, such as for example, flow chart programming, Ladder Logic, Instruction Lists, or Function Block Diagrams. Ladder logic (“LAD”) is one programming language used with PLCs. As is shown in FIG. 1, Ladder Logic code 10 uses graphical symbols that resemble electromechanical elements used in a relay logic diagram format to describe hard-wired control. The left vertical line of a typical Ladder Logic Diagram usually represents a power or energized conductor. A right vertical line, represents the return path of a hard-wired control line diagram, and may be omitted. Ladder Logic Diagrams are read from left to right, top to bottom. Rungs are often referred to as networks. A network may have several input and output instructions. Input instructions represented by a series of contacts, in one or more parallel branches, perform comparisons or tests, and are normally left justified on the rung. Output instructions represented by coils, for which there may only be one in each output branch, execute some operations or functions, and are normally right justified on the rung. As is shown in the exemplary Ladder Logic code 10 depicted in FIG. 1, I0.0, I0.1, and Q0.0 represent the first instruction combination. If inputs I0.0 and I0.1 are energized, output Q0.0 is energized. The inputs could be switches, pushbuttons, or contact closures. The output could, for example, be a solenoid or a light bulb. I0.4, I0.5 and Q0.1 represent a second instruction combination. If either input I0.4 or I0.5 are energized, output Q0.1 energizes.
An Instruction List (“IL”) provides another view of a set of instructions and is exemplified at 20 in FIG. 1. The operation, i.e., what is to be done, is shown on the left. The operand, the item to be operated on by the operation, is shown on the right. The LAD and the IL have a similar structure. The set of instructions in the IL 20 of FIG. 1 performs the same task as the LAD of 10.
Function Block Diagrams (“FBDs”) provide another view of a set of instructions and are exemplified at 30 in FIG. 1. Each function has a name to designate its specific task. Functions are indicated by a rectangle. Inputs are shown on the left-hand side of the rectangle and outputs are shown on the right-hand side. The Function Block Diagram 30 shown in FIG. 3 performs the same tasks as shown by the LAD 10 of FIG. 1 and the IL 20 of FIG. 1.
Programmable controllers in general, and PLCs in particular, execute program code in a repetitive process referred to as a scan. A scan may start with the CPU reading a status of inputs. The application program is executed using the status of inputs. Once the program is complete, the CPU performs internal diagnostics and communication tasks. The scan cycles ends by updating the outputs, then starts over. The cycle time depends on the size of the program, the number of I/O's, and the amount of communication required.
In order to write programming instructions and generate configuration data and download the code and configuration data to a programmable controller, several tools are needed. As is shown in FIG. 1, a programming device, such as a personal computer 1, is interfaced with a PLC 7. Typically, a proprietary cable 5, such as Siemens® PC/PPI, connects the computer's RS 232 port with the PLC 7. Prior to the present invention, engineering software tools 3, such as Siemens STEP 7,® had to be installed on the PC so that the PC might be used to write programming instructions for the PLC Typically, the engineering tools are sold on CD's or on another computer readable medium.
FIG. 2 outlines the typical steps and shortfalls that result from the purchase of a copy of an engineering tool. The customer of an engineering tool typically buys a copy of the software and obtains a license to use the tool, step 20. The customer must then install the software on a single customer computer, step 25. The customer can only develop application software, i.e. programming code for a programmable controller on computers that have the engineering tool, step 27. The license agreements typically accompanying engineering tools restrict the customer's ability to install the tool on more than one computer without paying for a license for any additional computers.
The software or engineering tools, such as Siemens STEP7® or MicroWin,® are often proprietary tools developed by the controller manufacturer. Typically, the development of these engineering tools takes thousands of person-hours. The tools are often designed and tested to work on a specific computer operating system, such as for example Microsoft Windows® 98. When the operating system for the computer on which the tool is used changes, the tool needs to be re-verified. Often, PC vendors deliver only the newest Microsoft operating system on their PCs. This forces the engineering tool vendors to also support the new operating system, which usually means additional hundreds or thousands more person-hours of investment. In many organizations, the operating system of the PC is updated without regard to the software, such as the engineering tools, residing on the PCs.
Engineering tools are often updated over time. Consequently, different version of the tools may exist at the same time. In a large manufacturing facility it is likely that not all the programming tools are using the same version. This not only increases the costs of ownership, but also can cause problems when different programming devices are used to write programming code for the same PLC application. Often, a team of engineers is assigned to program a PLC. Each engineer in the team may work independently on a discrete aspect of the application. At a later time, these various discrete aspects are combined into one program that operates on the PLC. If the engineers are not all using the same version of the tool, it is possible that the code generated from a version of the tool may not be compatible to an earlier version of that tool.
In addition to problems associated with running different operating systems on the programming devices and different versions of the engineering tools on the operating systems, the programming code for the programmable controllers is often not archived in a centralized manner. Often the code for one PLC in a factory may be stored on one laptop or desktop personal computer and the code for another PLC may be stored elsewhere. If a PLC were originally programmed with a first PC and that PC is latter replaced with a second PC and if the PLC reprogrammed with a second PC, there often would be no way to restore the original program, should the new program be deficient.